-
Notifications
You must be signed in to change notification settings - Fork 37
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
add formatting and linting python in pre-commit #370
Conversation
No ruff in the LCG releases? 👀 |
We either adapt that to run the same checks as this, or we have to include |
Added cmake targets here so #257 can be closed if this is merged |
b50f4bb
to
9a4aaed
Compare
Very nice. Thanks :) |
What about including formatting as part of |
I like the idea. We would probably then also need a pre-commit setup that checks in all repositories. In the end the targets are only defined but not run by default, so it would be a somewhat easy way for users to fix formatting issues that are flagged by pre-commit. |
Hmm pre-commit config is just a single file and if we want to centrally manage it then the projects are not supposed to modify it, right? |
I think some of the configuration files simply can't be managed centrally, or at least not for all packages. It's not entirely clear to me where to draw the line, but e.g. |
So should we centrally manage just the cmake target with ruff format but no linting target, pre-commit config, ruff config? Ruff can run on the defaults without any config file, the only difference between the defaults and the config here is the |
Maybe python related targets need to go into a separate I would leave the pre-commit config on a per repository basis at least. (The github action can then again be distributed centrally). For the linting, I am not entirely sure, in principle we should apply the same rules for all repositories. However, that would then mean that we would need to go the way of ruff specific config files, right? Because |
9a4aaed
to
b4d2337
Compare
Should we merge this still before the tag (tomorrow)? Or do we postpone this until later and conclude the discussion first? |
I think there is no hurry for this one |
b4d2337
to
b88ce89
Compare
b88ce89
to
e1bc290
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me, thanks. If nobody complains, I will merge this later today.
@@ -0,0 +1,5 @@ | |||
target-version = "py310" | |||
line-length = 99 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was just about to say we should add this. Nice :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I tried to be compatible with the black config from k4FWCore https://github.com/key4hep/k4FWCore/blob/main/pyproject.toml since at that moment that was the only python formatting config out there (except for spack I think)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Then let's put py310 in k4geo (@tmadlener)?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Updating to py311
here and in k4FWCore and reformatting doesn't change any files. We have python 3.11 in the nightlies. I think we could just update and have py311 everywhere
I can also copy the extra formatting options from k4geo (it's just being explicitly setting the values same as the default right?)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it's just being explicitly setting the values same as the default right?
Yes. Specifically the defaults that make ruff work / format the same as black.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we could just update and have py311 everywhere
I would be in favor of that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Updated here
There will in the next one: https://lcginfo.cern.ch/pkg/ruff/ (Hopefully happening Monday) |
We could also switch over to use a key4hep stack, since that is what we are doing on other repositories, I think. Using an LCG stack was done historically, because we could more easily get an LLVM based stack (for |
BEGINRELEASENOTES
ruff
andruff-format
to lint and format python codeENDRELEASENOTES
Linting and formatting done with ruff which should be compatible with black, flake8 and pylint while having a single configuration file. ruff is already in the stack
CI added as local hook
Selected rules
["F", "E", "W", "PLE", "PLW", "PLC"]
from flake8 (pyflakes "F", pycodestyle errors "E" and warnings "W") and pylint (errors "PLE", warnings "PLW" and conventions "PLC")I'd also consider adding some of the
D1
checks for docstrings but there seems to be only a few docstrings now 🙃The codebase seems to use mixed 2-space and 4-space indent, now the default 4-space is used in formatter
Should I also add cmake targets as in #257?
Closes #364